Skip to content

Conversation

@lumiscosity
Copy link
Contributor

@lumiscosity lumiscosity commented Jan 10, 2026

This should lighten the cost of the i18n infra a little. Some notes apply:

  • There are a few new entries in commonMessages - some are to address existing duplicate use cases, while some simply contain common strings that could be reused elsewhere in the future (or are used in other places which aren't translatable at the moment).
  • The translation key for commonMessages.privateLabel is now label.private instead of collections.label.private for consistency.
  • All entries in paymentMethodMessages are now in the payment-method namespace. paymentMethodCardDisplay has also been moved from commonMessages to paymentMethodMessages.
  • There is a lot of duplication within common-messages.ts itself, particularly between commonMessages and formFieldLabels, that this PR does not currently address.
  • The landing page has some duplicates in the Modrinth UI mockups. I'm not sure how to best deal with exposing the translation keys from the proper source for these so I'm considering this out of scope for this PR. Other duplicates of common messages on the landing page are adressed.
  • privateLabel, publicLabel and rejectedLabel are currently skipped, since they would need adjustment for grammatical gender in some languages. Ideally these should be split into project and collection labels at the very least; going deeper into project types would create a lot of duplication but technically be more proper for some languages... The same goes for the timestamps (updated/published/played/etc.).
  • There's a lot of very definition intertangled reuse of "Server", independently or in relation to "Client" ("Server and client" appears multiple times!). I'll adress this in a separate PR when unifying the translation keys for sidedness strings sitewide. This also affects singleplayerLabel.

@lumiscosity lumiscosity force-pushed the deduplicate-common-strings branch from 1f877f8 to 114bc5d Compare January 11, 2026 11:31
@lumiscosity lumiscosity marked this pull request as ready for review January 11, 2026 19:28
@IMB11 IMB11 self-assigned this Jan 12, 2026
@IMB11 IMB11 added frontend Involves work from the frontend team dev-ex Improvements to developer experience labels Jan 12, 2026
@IMB11
Copy link
Member

IMB11 commented Jan 12, 2026

Thanks for this PR, I will take a look shortly! 😄


<span v-if="props.option.type === 'card'">
{{
formatMessage(messages.paymentMethodCardDisplay, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you forget to update this? messages.paymentMethodCardDisplay does not exist anymore because of your refactors

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah, thanks for catching this! will fix in a sec

@IMB11
Copy link
Member

IMB11 commented Jan 12, 2026

This is a good start, don't forget to run pnpm prepr:frontend:web in the root folder to fix the lint issues.

@Jerozgen
Copy link
Contributor

These cases require separate strings for the Russian translation:

  • Created {ago} and Updated {ago} cannot be reused in Russian due to grammatical gender differences
  • Withdrawal Details are translated as "Реквизиты", which refers to payment or document details and fits the context better than the generic "details"

@lumiscosity
Copy link
Contributor Author

lumiscosity commented Jan 12, 2026

  • Created {ago} and Updated {ago} cannot be reused in Russian due to grammatical gender differences

got it! will roll it back for now and file it under the same grammatical gender woes as the project visibility labels.
(in Polish this can be worked around with impersonal form (past tense) - "utworzono", "aktualizowano", but i should've figured other languages don't have an appropriate way of dealing with it...)

  • Withdrawal Details are translated as "Реквизиты", which refers to payment or document details and fits the context better than the generic "details"

this one was an honest mistake, i wanted to keep it separate because it is a different context but i got distracted - thanks for catching that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dev-ex Improvements to developer experience frontend Involves work from the frontend team

Development

Successfully merging this pull request may close these issues.

3 participants